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BACKGROUND OF THE INVENTION 

1. FIELD OF THE INVENTION: 

The invention relates to a method o£ transferring data 
5 from a sender process to a plurality of receiver processes , 
at least some of which are described in a hardware 
description language, and to hardware produced in 
accordance with such a method. 

10 2. DESCRIPTION OP THE RELATED ART: 

Occam is a computer language in which some parts of 

a program may fce made to run concurrently (see inmos Ltd. , 

The 0ccam2 Re£ aranee Manual, Prentice-Hall International , 

1988} » The parts are called processes* The programmer 

« 

15 may declare synchronous channels. Each channel conneats 
exactly two processes in such a way that data can be sent 
from one (the sender process) to the other (the receiver 
process) synchronously. That is, if the sender starts 
to send first it must wait until the receiver is ready 

20 to receive, likewise if the receiver tries to receive 
first it must wait until the sender is ready to send. 

Therefore data is never lost by (say) the sender 
overwriting a previous message before the receiver re- 
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ceives it; and never received twice by {say) the receiver 
performing a receive twice without trie sender updating 
the content of the channel in between . 

5 For example , in Occam t 

CHAN OF INT ch: declare ch as an integer channel 

PAR 

SEQ — first prooesa 

--do some things 
ch I x send the value x down channel ch 

~ --do some more things 

SEQ second process (in parallel with first) 

--do some things 
ch T y receive a value from channel ch, 

and store in y 
do some more thing© 

The concrete syntax for send and receive may vary m 
20 other languages, for example send (ch, x) instead of ch 1 
x or y « receive (ch) instead of oh ? y- However the 
communication is always between precisely two processes , 



10 



IS 



VHDL is a hardware description language, which is also 
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used extensively for hardware synthesis (see Steve 
Carlson, Introduction to HDL -based Design Using VHDL, 
Synopsys Inc., CA, 1991 and IEEE Standard VHDL Language 
Reference Manual, IEB£ std 10/6-1993, ieee, New Yorfc, 
5 1993), Concurrent VHDL processes communicate by 
uneynchronised shared signals. One writer process 
(analogous to a sender ) may write a value to a signal, 
and one or several readers (analogous to receivers) may 
read that value. However, it is entirely up to the 
10 designer to ensure that written data is read whan it is 
valid by the readers* This can be done by building an 
handshaXe protocol 9 so that readers write to another 
signal (dedicated to this purpose) to indicate their 
status with regard to the data transfer . 

15 

For example, in VHDL you assign tha value of an 
expression E to a signal S with the construct S <- E, and 
read from a signal s just by using its name In an expression • 
Thera is no limit to how many processes may read from S 
20 (although only one may write to S unless the signal is 
declared with a resolution function). However there is 
no automatic synchronisation. Values may be read more 
often than written (and so data repeated) or written more 
often than read (and so data lost). 
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Bach (sea British Patent Publication No. 2317245) is 
a language similar to the software language of C, but which 
supports parallelism and communication like Occam, and 
5 which may be used to synthesis* hardware. (Because of 
this feature, the Bach compiler which compiles the Bach 
language into hardware is called a hardwarm compiler) . 
That is, the syntax ie like C (with extension©), but the 
semantics are more aKin to Occosu, with its parallelism 
10 and synchronised communication. In Baah data may be sent 
along synchronous channels as in Occam, 

Note particularly that communication is always one 
to one. One process sends, and another process receives* 
15 To send data to more processes requires more channels ♦ 

In addition there are global variables, which may be 
written and read by several processes, but without 
automatic synchronisation. It is possible to use shared 
20 variables to distribute information to several processes , 
but then there is no guaranteed synchronisation, and the 
user must invent an ad-hoc signalling system to ensure 
data is correctly transferred. In Bach such shared 
variables are called aahans for asynchronous channels. 
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For example/ in Bach* 

Void main (void) 
5 { 

chem int oh: // declare ch as a synchronised 
// channel carrying integer data 

par {{ 

// first process 
10 //do some things 

eend (ch, x)f // send the value x down 

// channel ch 

//do some more things 

}{ 

is // second process {in parallel with first) 

//do some things 
y ~ receive (oh); // receive a value from channel 

// ch, and store in y 
//do some more things 

20 >} 



The Bach compilers convert these constructs either 
Into software for execution on a microprocessor or into 
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a hardware description for the design of a special purpose 
integrated circuit. 



S SUMMARY OP THE INVENTION 

According to the invention there is provided a method 
of transferring data from o sender process to a plurality 
of receiver processes , wherein at least one of said 

10 processes is described in a hardware description language, 
said hardware description language incorporating 
simulation means for simulation of tne fcehaviour of 
hardware and also incorporating a hardware compiler for 
deriving hardware whioh behaves according to said 

13 simulation, and wherein the method uses a language 
construct which effects synchronised communication be- 
tween the sender process and the receiver processes • 

The method may involve carrying out a send algorithm 
20 under the control of a pre-emptive scheduler « 

The scheduler may ensure that the send algorithm is 
carried out without descheduling. 
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A checK may be made that all of the receiver processes 
are ready to receive data before data is transferred from 
the sender proaess to the receiver processes* 

5 The method may involve carrying out a receive 

algorithm under the control of a pre-emptive scheduler. 

The scheduler may ensure that the receive algorithm 
is carried out without descheduling. 

10 

At least one of said processes may be embodied in 
hardware « 

This is the so-called "hybrid" hardware -software 
15 implementation of the invention. 

Alternatively all of said processes may be described 
in said hardware description language, 

20 The invention also provides a synchronous electrical 

circuit produced by first simulating at least part of the 
circuit in accordance with the above method and then 
creating the alrcuit using said hardware compiler* 
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The synchronous electrical circuit may be a digital 
electronic circuit. 



The invention also provides a hardware description 
5 language adapted to simulate the behaviour of at least a 
sender process* and a plurality of receiver processes/ and 
comprising a language construct which effects synchronised 
communication between the sender process and the receiver 
processes. 

0 

The hardware description language may be adapted to 
carry out the above method* 



The invention also provides a computer readable 
13 medium carrying a computer program adapted to carry out 
the above method. 



In this way it is possible to extend a language like 
Bach to support what we herein call mult±-ch&nnmls , or 
20 mahans for short, A multi-channel is synchronous like 
an Occam channel, and permits multiple receivers like a 
VHDL signal. 



We provide implementations in both software and 
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hardware, so that a designer can simulate a design in 
software before synthesislng it in hardware, using the 
same design document. The hardware implementation in- 
volves creating a synchronisation block capable of 
5 synchronising an arbitrary (but fixed) number , n > 0, of 
processes (one sending, a - 1 receiving), and protocols 
which each sender or receiver must obey when performing. 
Possible implementations are given later. 

10 We add an extra data type specifier (arbitrarily given 

the name mchan) to the description language . For example, 
in Bach: 

15 mchan int ml; ' // declare ml as an f int f type 



multichannel 



par {{ 



// begin process branching 



// code for process 1 



send ( ml , x ) ; // send value of x on ml , and synch 



20 



// more code for process 1 



>{ 



// code for process 2 



y = receive (ml); 



// synchronise on ml, 



// store value in y 



10 
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// more code for process 2 

>{ 

~ // code for process 3 

2 » receive (ml); // synchronise on ml, 

// store value in z 
// more code for process 3 
>> // end process branching 



This example shows the declaration of a multichannel 
lo ml, and three processes which use it. The sender sends 
the result of any expression E to ml with the phrase send 
(ml, B) ; . In this case there are two receivers, and they 
may obtain the value sent by using the expression receive 
(ml) . The send end receive constructs will not terminate 
15 until the entire synchronisation is complete? that is, 
when the sender has executed send and all receivers have 
executed receive. 



In addition any receiver may use the 'ready' test, 
20 ready (ml) which is true if the sender has executed send 
but is still waiting for the synchronisation. The 
'ready' test finishes immediately (it doesn't wait for 
synchronisation) and it doesn't affect the behaviour of 
the other processes engaged in the synchronisation. 
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Suppose ml is declared as a multichannel. Not every 
process is recuired to be a sender or receiver for ml: 
this allows synchronisation o£ just a subset o£ processes, 

5 

only one process may be a sender for it, and this 
process is identified by the compiler as being the only 
one containing a fiend command for ml. Several processes 
may be receivers for ml, and these are identified as those 
10 processes containing the expression receive (ml). Mo 
process may be both sender and receiver for ml. 

This multichannel language primitive (ie. Additional 
part to the language) makes it easy for a designer to 
15 specify that a single process (software or circuit) 
controls and synchronises data transfer with a number of 
dependent processes (software or circuits }• 

The designer does not need to build an ad-hoc 
20 synchronising circuit each time as in VHDL. 

The implementation is cheaper than would be the set 
of at least N + 1 one-to-one synchronous sends that would 
be required in Occam (where N is the number of receivers) 
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or in Bach. The new method la therefore faster, and may 
require less silicon area (in a hardware implementation) 
or memory (in a software implementation) * 

5 Because hardware and software implementations are 

available multichannels can be added to a hardware 
compilation system such as Bach. 

BRIEF DESCRIPTION OF THE DRAWINGS 

10 

The invention will now be more particular described/ 
by way of example only, with reference to the accompanying 
drawings , in which t 

13 Figures 1(a), 1(b) and 1(c) show high level views of 

channels and signals? 

Figure 2 gives an algorithm for handling sends on 
mchannels ; 

20 

Figure 3 gives an algorithm for handling receives on 
mchannels ; 

Figure 4 gives a simpler version of the algorithm in 
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Figure 3 whiah is used when the data to be received on 
an mchannel is not used; 

Figure 5 shows one implementation of mchannel send 
5 in hardware, giving a state machine r 

Figure 6 shows one implementation of mchannel receive 
in hardware, giving a state machine? and 

10 Figure 7 shows one hardware implementation of the 

mchannel synchronisation block 6 of Flguxo 1(c), giving 
a possible digital circuit. 

DESCRIPTION OF THE PREFERRED EMBODIMENTS 

15 

Figure 1(a) is a high level view of a synchronous 
channel of the type used in Occam and Bach. A sender 
process 2 is connected to a recftivftr process 4 via a 
synchronisation block €♦ There is one sender 2 and one 
20 receiver 4, and these are synchronised* 

Throughout Figures 1(a) to 1(c) synchronisation 
signals 8 are represented by small arrows, and data 
signals 10 are represented by larger arrows. 
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Figure 1(b) ie a high level view of a VHDL signal. 
For convenience the same reference numbers are used to 
indicate the sender (or writer) process 2, the receiver 
5 (or reader) processes 4, and the data signals 10* The 
processes are unsynchronised. 

Figure 1(c) is a high level view of a multichannel 
in accordance with the invention. For convenience the 
10 same reference numbers are used to indicate the sender 
process 2, the receiver prooesses 4, the synchronisation 
block 6, and the synchronisation signals 8 and data 
signals 10. The processes (2 and 4) are synchronised by 
the synchronisation block 

15 

Software implementations of the invention will be 
described first, followed by hardware implementations* 

Algorithms for handling send and receive on mchannels 
20 will be described. These algorithms are intended for 
execution on a sequential computer which has a single 
processor. Some concepts and terms will first be ex- 
plained: 



99R00139 

- 15 - 

Each process is assigned a number called a process 
identifier (id for short) . No two processes have the seme 
id. 

5 Throughout, we will assume that the execution of 

processes is managed by a pre-emptive scheduler* Suoh 
a pre-emptive scheduler controls the time division of the 
execution of various processes. For example, processing 
can be shared between different processes, or the 

10 scheduler can instruct that a given process be completed 
before processing of the next process begins* Two 
procedures (or commands, i.e. "lock* and "unlock" ) are 
provided to interact directly with the scheduler! 2oek{) 
instructs it not to deschedule the current process, and 

15 unlock{) passes control back to it to run another {or 
possibly the same) process. That is, everything between 
looJc and unlock must be executed before any other process 
is executed. A set is used to store the processes which 
are ready to run. The scheduler dispatches items from 

20 it and terminates when there are no items left. Two 
procedures (or aommands) will be used to update the sets 
tt wake-up w adds process ids and "sleep" removes the id of 
the process currently being executed. Note that u waXe 
up" and u sleep" do not perform any scheduling or 
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descheduling, they simply affect which processae are 
available to be scheduled when the scheduler next runs* 

Certain information about mchannels must be stored. 
5 A convenient way of doing this ia to use the following 
functions: 

channel- reedy £ returns true if either a send or a 
receive has happened on a given mcfcannel. and re- 
10 turns false otherwise, 

data : returns the data most recently sent on a given 
mchannel . 

15 it is also necessary to find out Which sends and 

receives have happened. The following functions will be 
used for this purpose: 

sender / if a send has happened on a given inchannel, 
20 this function returns the process id in which the 

send can ha found, 

receivers : given an mchannel, this function returns 
the ids of the processes whose receives have hap- 
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pened. 

Variables used to receive data from an mchannel will 
be called destinations. For example, in the assignment 
x = reeeiv* (ch> , xie the destination. Not all receives 
have destinations, however. For example, in the fragment 
of code 

{ 

send (chl, d) j 
receive (ch2)? 

> 

receive does not have a destination. Such receives are 
used for synchronisation. Given an mchannel, the 
function destinations returns all the destinations in the 
processes whose receives have happened* 

As has already been mentioned, each send operation 
on an mchannel typically has several corresponding re- 
ceives. It is useful for our purposes to know the ids 
of processes in which the receives exist- The following 
can be used to find out this information . 
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reoelvos-on-mohannel returns the ids of the proc- 
esses which receive on a given mohannel* 

All o£ the functions we have presented will be viewed 
extensionally, i.e. as sets of pairs . For example, the 
function which maps 1 to 2, 2 to 3, 3 to 4 and 4 to 1 can 
be written as f = {(1,2), (2,3), (3,4), (4,1)} 

The algorithms will be presented in the form 
procedure -nam* (perimeter list} m 
procedure' body 

The procedure -body consists of assignments to the 
functions introduced above as well as calls to tne 
following procedures t lock, unlock, w&ko-vp, sleep and 
copy-data- to-d&stln&tlons. The purpose of copy - da La - 
zo-Cestinatlons is, as its name suggests, to copy a given 
piece of data to the destinations of a given mchannel* 

copy- date -to -destinations (d t ch) - 
for eacn x in destinations (oh) 

do 
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od 

The functions are not passed as arguments. Instead we 
assume that there Is a global state in which they exist. 
The reason for making this assumption is to simplify the 
presentation. 

We now focus our attention on the assignments. These 
assignments involve updating the function© introduced 
above. Set -theoretic operations can be used to perform 
the upflates. since the functions are sets of pairs, in 
particular, we will make use of the following i 

(a) union, written U, for combining two sets. For 
example: {1,2,3} U {2,3,4,5} - {1,2,3,4,5}; 

(D) difference, written - , for removing items from a set. 
Por examplet {1,2,3} - {2,3,4,5} = {1}; 

(c) domain co-reetriction, written < (in the figure© the 
same symbol ia used, except that it has a horizontal 
line through the centre), for removing pairs whose 
first component is in a given set, Por example 
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taking the set of pairs u f w given above, then {1,2} 
< f does not map 1 and 2 to anything. 

(d) function override , written ®, for modifying a 
5 function. To illustrate this, consider the function 

f again. If we want r to map 1 to 3 (Instead of mapping 
1 to 2), we could write £ © {(1,3)}. 

Two further symbols from set theory will be use&t # 
10 and 0. The first of these returns the number o£ items 
in a set, and the other stands for the empty set. 

Wft are now in a position to present our algorithms 
for eend and receive. The algorithm for send, shown in 
15 Figure 2, is the simpler of the two, and so will be 
described first- It consists of four parts t 

(1) First the scheduler is instructed not to fleschedule 
the current process (box 11) 

20 

(2) The Id of the process containing the send and the 
data to be sent are both recorded. The mohannel on 
which the data Is to be sent is set to READY (box 
12) . 
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Next a aheck is raadc to sec whether all of the receives 
have happened (i.e. all of the receivers are ready 
to receive) (box 13). If they have, the data can 
be received by all of the receivers* This entails 
the following (box 14) t 

copying data to the destinations; 

putting the current process to eleep and waking 
up all of the receivers? 

resetting the information stored about the 
mchannel, i.e. setting the mchannel to NOT READY 
ana clearing each of the following: the data sent 
on the mchannel, the destinations for the 
mchannel, the sender for the mchannel, the 
receivers for the mchannel. 

the process is then put to sleep. 

If there are still receives to arrive, however, the 
process has more work to do at later time and so is 
put to sleep (box 15). 
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(4) Finally, control ie handed back to the scheduler a< 
that it can select another process (if any) to run, 

The algorithm is given bolow; 

sendfpid, d, oh) « 

sender :■ sender U {(en, pld)): 
channel-ready i= channel -ready © {READY}; 
date 5= data U Uvh, tf)>; 

if # receivers {ch) = # [receives -on-mchannBi ich)) 
then copy-date- tc-das tine tlons (d, eh) t 
nroJce - up { racal vers {ch)); 

channel - ready •= channel - ready & {{ah, NOT 
READY)}; 

data ;« {oh} < date; 

destinations j« destinations © £5)}: 

sender ; - {cA} < sender-} 

receivers {c/?} < receivers : 
sleep{ ) • 

o-Z^o sieep (); 

unloak{ ) 
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The algorithm for receive is more involved, and is 
shown in Figure 3. One© again/ it consists of four parts ; 

(1) first the scheduler is instructed not to deschedule 
5 the current process (box 16) 

(2) the id of the process containing the receive is 
recorded and so is the destination (bo$c !?)♦ (If 
there happens to be no destination, destinations 

10 does not need to be updated. ) 

(3) next, a check is made (box 18) to see whether the 
following conditions are satisfied? the mchannel is 
ready and all of the receives have happened. If both 

15 of them are satisfied, it means that a send has 

happened (and so data is waiting to be received) and 
all of the receivers are ready to receive* Thus it 
is safe to receive data. This entails the following 

(box 19): 

20 

- copying the data to the destinations; 

- waking up the process which sent the data; 

- waking up the receivers, except the one that 
has just happened; 
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- resetting the channel (same as m The send 
algorithm) 

- the process is then put to sleep ♦ 

5 If either one of the two conditions does not hold, 

the process is put to sleep (box 21). 

(4) Control is handed back to the scheduler. 

io The algorithm for receive is given below- 

receive {ch, pid, y) = 
lock{ ) ? 

receivers t - receivers © {{ch, ireaei vers {ch) U {pid})*)-, 
15 destinations := destinations ® i{cn, destinations {an) 
U iy})}; 

If channel-ready {ch) & # receivers {ah) - # receives- 
on-mchannel (cn) 

then copy -data -to -destinations (data {ch) , ch) ; 
20 wake-up {sender {oh))} 

wax e- up {receivers {on) - {pld}); 
channel -ready : - channel -ready © { ( ch, 
NOT READY)}; 
data t- {chy < data* 
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destinations destinations © {(ch, 0)}. 
sender ; = {oh} < sender) 

receivers :« {ch} < receivers 4 , 
sleep ()* 

else sloop ( ) ; 

unlock { ) 

As mentioned above, a receive may have no destination. 
The algorithm for receive can be simplified to cater for 
th1.fi situation, as shown in Figure 4. Here is th* 
simplified algorithm; 

recelve2 {ah, pld) = 
lock <V; 

receivers : = receivers® {(ch, receivers (ch) U {pld} }}; 

channel-ready (ch) £ # receivers (ch) » # receives- 
on-mchannel (ch) 

then copy-data-zcdestlnatlcns {data (ch) , ch) t 
waks-up (sender (ch))t 
wake-up (receivers (ch) - {/?i</}) ; 

channel -reedy *a channel -reedy ® {(cA, MOT 
READY)}; 

destinations destinations ® {(ch, 0)}; 
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sender := {ah} < sender; 
receivers := {<?A} < receivers; 
sleep {); 

unlooJc ( ) 

A hardware implementation will now be described- 
This uses a synchronous clock common to all the processes. 

Figure 5 shows the hardware implementation of a send 
operation , as a state machine. In the first state the 
value to be sent by sender 20 is connected to the daw 
wires 21. Next the sr (sender ready) signal on the sender 
ready output 22 is set true, to indicate that the data 
is valid. In state 3 the sender waits Until the synch 
signal on the synch input 24 is true. Then it sets mt 
back to f alse / ready for the next communication. Finally, 
it may continue with its normal operation, states l and 
2 may be completed in the same clock cycle. Step 4 must 
occur after the start of the cycle in which synch is true, 
and before the start of the next cycle. 

Figure 6 shows the hardware implementation of the 1th 
receive operation, in the first state the receiver 26 
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sets its individual receiver ready signal rr A on receiver 
ready output 28 to true. Then it waits for the shared 
synch signal on synah input 30 to go true* la the next 
Clock cycle it must transfer the data value from the data 
5 wires 32, and set the jtjt s signal back to false. Then it 
may continue with normal operation. 

Figure 7 shows the hardware implementation of the 
synchronisation block 34 used in the hardware 

10 implementation. Th« data signal on data wires (21, 32) 
is passed straight through and distributed to all the 
receivers 26 . The sender ready signal sr on sender ready 
input 36 and receiver ready signals -r^ on receiver ready 
outputs 38 for all receivers 1 ~Jf are combined by logical 

15 AND gate 40. The result is a signal called synch and is 
passed to the sender and all the receivers on synch outputs 
42. 

Finally, if the ready test function is used by one 
20 or more of the receivers 26/ then the sr signal must be 
distributed to all receivers 26 which do so. The value 
of the test ready (m) on this channel at any moment is 
equal to the value of the signal sr. 
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Note that in addition a mixed so ft ware- hardware 
implementation may be created. Each sender or receiver 
may be an item of pure hardware / or else a cpu with 
Circuitry and instructions capable of changing and/or 
5 sensing the appropriate signals {er, rr, synch, data etc* ) - 
Provided that the protocol is followed correctly (which 
la achieved usually by a finite state machine in the ease 
of hardware, or by a program in the case of software) then 
the communicated data will be correctly transmitted. 

10 

I£ mchanncls are to be used with the Bach system, then 
there must be an algorithm for creating the circuit from 
the source description, which is given below. 

15 Each process in Bach is Implemented as a circuit, and 

a process which branches into subproaesses gives rise to 
more than one circuit. As an optimisation one subprocess 
branch may be subsumed within the parent process 1 s circuit , 
while the others produce distinct circuits. To 

20 communicate between these circuits wires are used, or 
perhaps wires together with logic and storage (for example, 
for modelling shared variables and channels ) , and these 
are referred to as resources. This is more fully de- 
scribed in British Patent Publication No. 2317245, 
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The algorithm for creating the circuit from the source 
description is as follows. First, examine the source and 
discover which mchannels are declared. There will be one 
5 mchannel resource for each mchannel in the source* 
consisting of wires to and from the reading and writing 
circuits and a synchronisation block- For each mchannel, 
mah, determine how many receivers are required - there 
will be just one process containing send instructions for 
10 meh, and may be several processes containing receive 
instructions for mch. This information allows the synch 
blocks to be built, and connected in the appropriate way 
to the reading and writing circuits - 

13 The invention can be used for a complex design with 

many almost -independent blocks, processing chunks of data 
in parallel without communication, but in synchronisation* 
h controller may communicate with the blocks to pass them 
configuration data on each cycle, by sending to an 

20 mchannel for which the blocks are all receivers. Using 
mchan means that all blocks will synchronise and change 
configuration together. Different mchane could be used 
to communicate with particular (pre** determined) subsets 
of the blocks. 
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Tho invention can also be used for system where a 
controller reads data from somewhere and passes it to a 
number Of Slaves which will aach perform it« own function 
on the data before reading the next block. If the 
controller sends data by mchannel then all the data 
processing is aaaily kept in step. 
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WHAT IS CLAIMED ISt 

1. A method of transferring data from a sender 
process to a plurality of receiver processes, wherein at 
least one of said processes la described in a hardware 
description language, said hardware description language 
incorporating simulation means for simulation of the 
behaviour of hardware and also incorporating a hardware 
compiler for deriving hardware which behaves according 
to said simulation, characterised in that the method uses 
a language construct which effects synchronised 
communication between the sender process and the receiver 
processes . 

2. A method as claimed in claim 1* which involves 
carrying out a send algorithm under the control of a 
pre-emptive scheduler. 

3 . A method as claimed in claim 2 , characterised in 
that the scheduler ensure© that the send algorithm is 
carried out without descheduling. 

4* A method as claimed in claim 2, characterised in 
that a check; is made that all of the receiver processes 
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are ready to receive data before data is transferred from 
the sender process to the receiver processes. 

5. A method as claimed in claim 1 which involves 
carrying out a receive algorithm under the control of a 
pre-emptive scheduler. 

6. A method as claimed in claim 5, characterised in 
that the scheduler ensures thai the receive algorithm is 
carried out without deschadullng. 

7. A method as claimed in alaim 1, characterised in 
that at least one of said processes is embodied in 
hardware * 

8. A method as claimed In claim 1, characterised in 
that all of said processes arc described in said hardware 
description language . 

9. A synchronous electrical circuit produced by 
first simulating at least part of the circuit in 
accordance with the method of claim 1, and then creating 
the circuit using said hardware compiler. 
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10 . A synchronous electrical circuit as claimed in 
claim 9, which is a digital electronic circuit. 

11. A hardware description language adapted to 
simulate the behaviour of at least a gender process and 
a plurality of receiver processes, and comprising a 
language construct which effects synchronised 
communication between the sender proaees and the receiver 
processes. 

12. A hardware description language adapted to carry 
out the method of claim 1. 

13. A computer readable medium carrying a aomputcr 
program adapted to carry cut the method of claim 1. 
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ABSTRACT 

A method is provided o£ transferring data from a sender 
process to a plurality of receiver processes in a hardware 
description language, which uses a language construct 
which effects synchronised communication between the 
sender process and the receiver processes. 
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sender:=senderUj(ch,pid)j 
chcnneLreadyr-channeLready © KcMREADY})j 



12 




eopy_data_to_destinations(dato(ch),ch) 
wcke_up(receivers(ch)-{pid}) 
channe!_ready:=chcnnel_.ready © {(ch,NOTREADY)} 
destinations:=destinotions ® [(ch.tf)} 
data:={chj ^ data;sender:={chj sender 
receivers: -|ch} receivers;sleep() 




Algorithm for send 
FIG 2 
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receivers:=receiver5 © {(ch,receivers(ch)Ujpid$)} 
destinotions:=destinations © {(ch,destindt?ons(ch)U[y£)j 
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channel_ready(ch)&#receivers(ch) 
#receives_on_mchannel(ch) 



NO 
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copy_data_to_destInotions(data(ch),ch) 
wake_up(sender(ch)) 
wake_up(receivers(ch)^|pid|) 
channeL.ready:=channeLready © j(ch,NOTREADY)| 

destinotions:»destinations (& i(ch,0)} 
data:={ch| data;sender:=jchj sender; 
recelvers:=|ch} receivers;sleep() 




Algorithm' for receive 
FIG 3 
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lockQ 



f 

receivers:=receivers © |(ch,receivers(ch)Uipidj)| 




copy_doto_to_destinotions(datc(ch),ch) 

destinations:==destinat?ons © j(ch,0)| 
wake__up(sender(ch)) 
wake_up(receivers(ch)-jpid}) 
channel_ready:=channe!_ready® j(ch,NOTREAOY)j 
sender:-* }ch| sender;dato:={chj data 
receivers:=jch} <^ receivers;sleep() 




Algorithm for the simplified receive 
FIG 4 
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J. set 'data' to value to be sent 

2. set 'sr' to true 

3. wait until 'synch* is true 

4. set 'sr' to false 



Hardware implementation of send 
FIG 5 
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1. set Vr(i)' to true 

2. wait until 'synch' is true 

3. copy data from 'data* 

4. set 'rr(i)' to false 



Hardware implementation of receive 
FIG 6 
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